Recently, multiple system cable operators (MSOs) have been transporting ever increasing numbers of variable bit rate (VBR) video. These VBR videos have been delivered primarily over Internet Protocol (IP) networks and mainly viewed on personal computers (PCs). It is very likely that these IP video providers will become more popular and will increase the durations and the bandwidths of these VBR videos. The VBR videos are also likely to be delivered to IP enabled set-tops and viewed on larger screens.
IP video is encoded and delivered differently from the usual cable company provided Video on Demand (VoD) provided over hybrid-fiber coaxial (HFC) networks. IP video is generally encoded as VBR and stored as a VBR file accessible through the content provider's web site. When a subscriber selects such a VBR video, a download is started, usually using a Transmission Control Protocol (TCP) session. A certain amount of the VBR video is buffered at the decoder (the receiving PC). The VBR video then begins to play, while the rest of the VBR video file is downloaded. The download over TCP can be at a constant bit rate (CBR) or at a VBR. The amount of video material in the decoder buffer can be substantial. Since the playback begins before the download has finished, the basic requirement is that the buffer not empty during the video playback. One important feature to recognize here is that the use of the buffer decouples the transmission rate of the video from the playback rate of the video. That is, the video may be played back at a different rate than the rate at which the video is transmitted over the network.
It is important to distinguish the system for VBR video intended for transmission over an IP network, described above, with the usual constant bandwidth CBR digital video used in some cable systems for transmission over an HFC network. For purposes of allocating bandwidth in a cable system using an HFC network, it is useful to allocate a fixed or constant bandwidth to each video flow. These video flows are carried on quadrature amplitude modulation (QAM) carriers with fixed bandwidths. In this way, a known number of video flows may share a QAM carrier.
Additionally, in a typical HFC cable system, VoD is based on digital transmission to a set-top box (STB) that has only minimal buffering. Often, the STB buffer is on the scale of a second or less. Because of the small size of STB buffers, the video transmission rate in HFC networks can be approximately equal to the video playback rate. The playback rate is by definition equal to the encoding rate. Therefore, in order for a video to be transmitted at a constant bit rate, the video must also be encoded at a constant bit rate. This is how conventional digital video transmitted over HFC cable systems is handled. The video is encoded at a CBR, it is stored in a server, and it is transmitted at a CBR over the HFC network to a STB, which may have a relatively small amount of buffering capacity. Generally, the playback of the video is also at a CBR. In this way it is possible to allocate the bandwidth on a QAM carrier to several video flows.
There is a problem, however, with encoding video at a constant bit rate. The complexity of the images within a video will inevitably vary. In order to maintain a consistent accuracy or fidelity in the more complex images, the bandwidth of the encoded video must also change over time as the complexity of the image varies. This results in VBR videos having different levels of data required to encode the different images. For instance, high definition VBR videos can reach instantaneous rates in excess of 16 Mbps for MPEG2 compression and in excess of 8 Mbps for MPEG4 Advanced Video Coding compression.
Due to the uneven bandwidth utilizations associated with the transmission of VBR videos, it would be difficult for the MSOs to transmit VBR flows to conventional STBs having small buffers. Due to the small buffers in conventional STBs, both the encode/decode rates and the transmission rates would have to be equal, and would have to both be VBR. Further, it is difficult to achieve a high average channel utilization for multiple VBR video flows. For instance, situations often arise where the total bandwidth for the multiple VBR video flows exceeds the capacity of the channel, which substantially limits the number of VBR video flows that are transmitted over the channel. In addition, if the average of the sum of the instantaneous VBR video flows is close to the capacity of the channel, there may be unacceptable delays in some of the video packets, degrading the operation of the video decoders. A proposed solution is channel bonding, which increases bandwidth to improve statistical multiplexing of video flows; however, channel bonding is oftentimes prohibitively expensive to implement.
To enable CBR transmission, CBR encoding is also required in typical cable systems. Therefore, in a typical digital video-based VOD system, the video is forced to be CBR encoded. This has led to capping, or artificially limiting the video bandwidth during encoding. In this way, the video can then be transmitted as a CBR flow. Unfortunately, capping the video bandwidth at a CBR encoding will result in a degradation of the video quality for the more complex images, which cannot be fully encoded within the bandwidth cap.
With respect to FIG. 1A, there is shown a block diagram of a conventional system 100 for sending VBR videos as a CBR flow. The system 100 may represent an HFC and/or an Internet Protocol (IP) network and, thus, includes a head-end 102, a user media device 108, and a display device 112. The head-end 102 includes any reasonably suitable device or combination of devices for receiving and/or storing media content and transmitting the media content downstream in a network, as is known in the art. As FIG. 1A shows, the head-end 102 contains media files 104, which are stored in a VBR format. Thus the encoding can be of a high fidelity and not subject to any arbitrary bandwidth limits in the video decode or playback rate. The video playback rate equals the encode rate which may not be equal to the video file download or transmission rate. The media file 104 may include any form of media content including videos, such as movies, television programs, etc.
The media file 104 is transmitted downstream under a CBR flow 106 to a user media device 108. The CBR flow 106 may be sent over any fiber and/or coaxial cables, such as a DOCSIS channel. Because, the media file 104 is sent as a CBR flow 106, the bandwidth at which the media file 104 is transmitted is capped, as described in greater detail below with respect to FIG. 1B. The user media device 108 includes, for instance, an STB, a digital video recorder (DVR), a modem, or a computing device. Generally speaking, the user media device 108 buffers and/or stores the media file 104 and plays back the media file 104 under a VBR flow 110 to the display device 112, which includes a television or monitor. In this manner, the media file 104 is transmitted to a subscriber's premises using the benefits of a bandwidth-capped CBR flow, yet the media file 104 is viewed on the display device 112 at full VBR quality.
With respect now to FIG. 1B, there is shown a graphical representation of media content transmitted as both a VBR flow 120 and a CBR flow 124. For example, the media content shown in FIG. 1B may represent the media file 104, or a portion thereof, described above, with respect to FIG. 1A. It is important to note that the video is encoded in a VBR format with no limits or caps on the encode bandwidth. By definition, the instantaneous encode rate, playback rate, and decode rate are always equal to each other. In this case the encoding is VBR. For the portions of the video that are more complex, the encode/decode bandwidth will be higher. The x axes of the graphs represents time while the y axes of the graphs represent an amount of bandwidth required to transmit the media file 104. For instance, the y axes may be measured in a number of bytes of data.
The upper graph of FIG. 1B shows the media file 104 transmitted as a VBR flow 120. Here the video file transmission rate is equal to the encode/playback rate. This would be the case where the decoder has a minimal buffer capacity. In the VBR flow 120, the media file 104 has a series of peaks 121 and valleys 122. The peaks 121 represent portions of the media content within the media file 104 that requires large amounts of data, such as action scenes, explosions, etc., which may have a wide variety of colors, color changes, scene changes, etc. The valleys 122 represent portions of the media content within the media file 104 that requires relatively smaller amounts of data.
The lower graph shows the same media file 104 transmitted as a CBR flow 124. Here the video file transmission rate is made unequal to or is decoupled from the video encode/decode rate. This approach requires a relatively larger buffer in the STB.
As described above, transmitting the VBR encoded media file 104 as a VBR flow 120 consumes bandwidth and limits the number of video flows that may be transmitted over a network because of the extra bandwidth required for transmission of the peaks 121. In order to enable greater number of simultaneous video flows, the VBR encoded media file 104 is sent as the CBR flow 124.
In some systems, the video is encoded not as VBR but as CBR. In this way, the CBR encoded video file may be also transmitted as a CBR flow over the network to a conventional set-top that has a minimal buffer. However, in this encoding, the portions of the video that are highly complex will be artificially capped in their bandwidth. In the context of FIG. 1B, the peaks 121 that exceed the bandwidth cap 123 are essentially cut-off, which often results in a decrease in quality of the media file 104 playback.
To overcome this loss of video quality the video can be encoded not as CBR, but rather as VBR content. The file is then downloaded as a CBR flow 124, often using protocols such as TCP/IP. In this case, the encode/decode time scale is decoupled from the file download. The net result is that the portions of the media file 104 which exceed the bandwidth cap 123 are redistributed to other portions of the media file 104 that are below the bandwidth cap 123. The bandwidth cap 123 thus represents the average bandwidth of the VBR media file 104. As a result, the entire media file 104, including the peaks 121 exceeding the bandwidth cap 123, are transmitted as the CBR flow 124 without having to perform a transcoding and/or transrating process, which may degrade the quality of the media file 104. The media file 104 is received by the user media device 108, reconfigured to its original VBR format, and played back to the display device 112 at full VBR picture quality.
While this solution allows a VBR media file to be transmitted as a CBR flow 124, other problems that limit a user's interactivity with the media file 104 remain. For example, the technique described above of sending a VBR media file as the CBR flow 124 does not allow for trick plays in the playback of the media file 104. Trick plays include fast forwarding and skipping to various points in the media file 104, which have not been downloaded or buffered to the user media device 108. For instance, trick plays include skipping to, or otherwise selecting, a different chapter in a movie. In current systems for transmitting a VBR media file as a CBR flow, an attempt to execute a trick play may result in interruption of the play back of the media file 104 causing choppy playback, delays in playback, and blank screens shown on the display device 112, thus creating an unpleasant viewing experience.
Therefore, it would be beneficial to allow for uninterrupted VBR playback of a media file while enabling trick plays in a system transmitting VBR video content as a CBR flow, without suffering from the disadvantages associated with conventional VBR video transmission techniques.